Fabless System-on-a-Chip (“SoC”) designers combine (3PIP) cores with in-house to design SOCs. They then outsource the fabrication and test phases of the SOCs. 3PIP vendors, foundries and test companies are distributed throughout the world. A SoC designer can use their service to meet the tight time-to-market deadlines, and to reduce the design, fabrication and test costs.
Notwithstanding its benefits, globalization of the SoC design flow has created opportunities for rogue elements within the supply chain to corrupt the integrated circuits (“ICs”). (See, e.g., References 1-3). Rogue elements in a foundry can alter a design, or include malicious circuits (e.g., called hardware Trojans), during fabrication. Similarly, rogue elements in the 3PIP companies can insert Trojans into their own IP. The inserted Trojans can be conditionally triggered or always on. (See, e.g., References 2 and 3). When triggered, a Trojan can result in a deadlock or failure of the system (e.g., overt attack), or can create a backdoor facilitating the attacker to gain remote access to the system (e.g., a covert attack). (See, e.g., References 2 and 3).
To provide a trustworthy SoC design, it can be beneficial to ensure the trustworthiness of the 3PIPs. However, since this may not always be possible, the SoC integrator should ensure that all the security vulnerabilities in any of the 3PIPs can be detected, or their effects muted, before they can damage the system.
Since 3PIPs can typically be delivered as Register Transfer Level (“RTL”) VHSIC Hardware Description Language (“VHDL”)/Verilog codes, code coverage analysis has been used on RTL codes to identify suspicious signals that can potentially be a part of a Trojan. (See, e.g., Reference 5). Since even a 100% coverage of the RTL code in a design does not guarantee that it can be fault-free (see, e.g., Reference 6), there is no guarantee that the 3PIPs can be trustworthy.
In another set of techniques, it has been proposed to analyze the 3PIP code, and mark suspicious signals. (See, e.g., References 7 and 8). The SoC integrator can then manually analyze these signals, and identify any Trojans. This technique, however, may also not guarantee Trojan detection, and can burden the SoC integrator by requiring them to manually identify the Trojans. In such a case, Trojan detection capability can depend on the skill of the SoC integrator. Furthermore, researchers have successfully bypassed this Trojan detection technique. (See, e.g., References 9 and 10). While probability analysis can be used to mark suspicious signals, controllability and reachability metrics can also be used to mark suspicious signals. (See, e.g., References 7 and 8).
Alternately, the SoC integrator, and a 3PIP vendor, can agree on a pre-defined set of security-related properties, and the SoC integrator can check the 3PIP against these properties. (See, e.g., Reference 11). However, a design methodology to develop the security-related properties for a 3PIP can be beneficial.
Thus, it may be beneficial to provide an exemplary system, method and computer-accessible medium for security verification of 3rd party intellectual property cores, which can overcome at least some of the deficiencies described herein above.